Bounded Context
参考
マイクロサービスの文脈
大きめのプロダクトを複数チームで作る際に、
プロダクト全体のユビキタス言語を統一したり、するのではなく、
境界を明確に引き、その中で統一性を保とう、という感じかなmrsekut.icon プロダクト全体で統一使用することは現実的ではないし、コストにも見合わない
そこで、文脈によってモデルを切り分ける
例えば、ステークホルダーごとに異なる概念であるような「決済」について、
複数チームが無理に同じclassで実装しようとして悲惨な目に合った的な話が『エリック・エヴァンスのドメイン駆動設計』.icon p.339-340に書いてる
でかいプロダクトの方がイメージしやすい
例えば服の会社内で、商品という用語1つとっても、
服を作る人からすれば、売値とか在庫数が関心事だが、
配送を管理する人からすれば、配送先や配送状況が関心事になる
これを一緒くたに扱うのではなく、別の文脈です、と区別する
最初から読んでないので、ここで言う「モデル」が何を指しているのか曖昧 #?? EntityやRepositoryなどの集合のことを1つのモデルとよんでいるのか？
大きいプロダクトかどうかはあまり関係なさそう？
まず前提の問題として、
人間間は別のものだと捉えているものを
同じ実装で表現している
というズレが問題
人間間というのは、少人数チームの2人かもしれないし、
別のチームのことかもしれない
まずここがズレていたらだめ
その上で、指している対象は同じっぽいが、微妙に違う、という時に
もう別物として作っちゃう、という判断も必要になる
一緒にできるなら一緒にしても良い
とにかく、別物として作ったものは、明確に別物だよ、というのが伝わる状態でないといけない
別物のモデルを同じものだと捉えることで問題が起きる
その外のことは忘却する
ただし、内部では完全に一貫したモデルを共有する
どうやって境界を作るか？
明示的な境界は、チーム編 成、そのアプリケーションに特有の部分が持つ用途、コードベースやデータベーススキー マなどの物理的な表現などの観点から設定すること。
まあそうなりそうだよねmrsekut.icon
同じコードベースでルールで境界付けるの運用でカバーなので辛そうだし
逆に言えば、同じチーム内では同じモデルを扱うようにしましょうとも言える
モデル(?)レベルの話で言えば確かにbounded contextみたいなのは必要というのはわかる
ただ、これってもっとミクロのmoduleの話でも同じではmrsekut.icon
module内で複数の同一モデルが出現することはそうそうないだろうけど、
moduleはmoduleの役割を果たせば良いだけで、外部のことはどうでも良い、という意味では同じ
と思ったら違うと書いてた
しかし、モジュールは1つのモデルの中で複数の要素を構成するものでもあり、
mrsekut.iconが思ってる「module」と違う気がするmrsekut.icon
別のコンテキストに対して、 必ずしも意図を伝えるものではない。
これはまあわかるmrsekut.icon
境界づけられたコンテキストの中でモジュールが個別の名前空間を作 成することにより、
実は、偶発的に発生するモデルの断片化が見つけにくくなっているのだ。
bounded contextは「同じ文脈内に、同じようなものがないぞ」という主張に力点が置かれているということだろうか？
context同士はeventでやりとりをする
ただ、それがqueueなのかDBを経由するのかは後で考えれば良い
Contextの中では正しいデータであることを保証する